Generally, a compiler operating on a computing device, such as a smart phone or personal computer, may perform inline expansion (i.e., inlining) to optimize code. To speed up execution, a compiler may “inline” code by replacing a call site (i.e., the portion of code making a method or function call) with the code body of the called method or function. Inlining code at call sites can significantly improve performance at runtime by reducing execution overhead and time and memory usage and by enabling other optimization opportunities. For example, inlining a call site may avoid overhead associated with making a method or function call, including having to save variables into registers or random access memory and then having to restore those saved variables after the called method is performed. Inlining code may also remove other costs of function calls and return instructions, such as prologue and epilogue code.
However, inlining, especially excessive or unthrottled inlining, may increase the time that a compiler must spend to compile the code (i.e., the compile time). Code compilers expend a great deal of compiler time managing register allocation, which is the most time intensive portion of code generation/compiling. Inlining may increase compile time by adding numerous variables to the code from the called functions. For example, a code compiler may spend a significant amount of time performing register matching when inlining results in code that requires more registers than are available on the underlying computing device.
While such expenditures of time is not an issue with off-line compilers, such time, memory, and processing expenditures are significant for compilers that execute when an application is started (i.e., compile at the time of execution). As the use of smart phones, tablets, and other mobile computing devices that depend on batteries continues to rise, expending battery life has become an increasingly important design consideration. A computing device's power expenditure and code's compile time are strongly correlated. Thus, longer compile times caused by excessive inlining may use significant amounts of battery power, thereby limiting battery life on mobile devices.
Currently, there are several techniques for selectively determining when to throttle inlining of a method or function during compiling. For example, one solution (i.e., a “greedy” inlining algorithm) defines a threshold of how much of the code (e.g., how many bytecodes) may be inlined, and the compiler inlines as much of the code as it can until the threshold is exceeded. Another technique known as frequency- or temperature-based inlining determines the methods or functions that are called with the highest frequency, and the compiler inlines those methods or functions until it has reached a certain threshold, such as a number of bytecodes. In the frequency-based inlining algorithm, those methods or functions that are not used frequently are not inlined.
While current methods of inlining provide some degree of code optimization, these strategies are typically implemented on computing devices that do not rely on battery power (e.g., a PC) and are not designed to reduce compile times.